Retail transaction promotion system

ABSTRACT

An augmented point of sale system that displays, and that may broadcast, during a retail transaction, promotional information to a customer selected on the basis of the context of the transaction. An existing front-end POS system is augmented with an auxiliary display device intended for viewing by a customer while the customer interacts with the sales clerk in order to conduct a retail transaction. Software components are added to the point of sale system in order to generate messages corresponding to events that occur during the transaction and to, in turn, translate those events into display images displayed on the auxiliary display device. The auxiliary display device can display text, broadcast music or audio information, show video clips and other real-time dynamic media, and display static images.

TECHNICAL FIELD

[0001] The present invention relates to point of sales systems forconducting retail transactions and, in particular, to a method andsystem for displaying and/or broadcasting promotional and informationalmessages to a customer during a retail transaction.

BACKGROUND OF THE INVENTION

[0002] Point of sale (“POS”) systems have been commonly implemented withproprietary cash register machines linked through a communicationsnetwork to one or more backroom servers. Recent advances in computerhardware, manufacturing processes, operating systems, and softwaredesign methodologies have made possible new generations of POS systemsbased on personal computer (“PC”) technologies. Both traditional POSsystems and new generation PC-based POS systems provide both valuableinformation collection services and basic facilitation of retailtransactions. However, POS systems currently provide relatively minimalfeedback to the customer, generally a sales receipt and possibly displayrepresentation of a sales transaction, as discussed above. In somecurrently available POS systems, various advertisements and consumerinformation may be printed on the sales receipt or displayed on aauxiliary monitor or LED display. However, these currently available POSsystems lack the capability of complex scripted tailoring of promotionalinformation or advertisements to a particular customer within thecontext of the current retail transaction. Instead, advertisements andinformation are printed or displayed identically to each customer, on arandom basis, or on the basis of simple item code matching. It would bedesirable, for example, for a retail merchant to designate, within thePOS system, particular promotional information tailored to particularcustomers based on the specific details of a retail transaction and onpreviously collected and processed information, including the loyaltyinformation discussed above. Thus, purchase of a particular item by aparticular customer might trigger an evaluation based on multiplevariables within the transaction that leads to a special message oradvertisement, including, for example, a discount or bonus computed fromthe evaluation. The need has therefore been recognized by retailmerchants for POS systems with real-time, context driven promotionalcapabilities.

SUMMARY OF THE INVENTION

[0003] The present invention provides an augmented POS system thatincludes capabilities for real-time displaying and broadcasting ofcommercial information within the context of a retail transaction. Eachfront-end POS system is augmented with an auxiliary display or combineddisplay and audio broadcast device for presenting promotionalinformation to a customer during the course of a retail transaction. Theauxiliary display device displays and may broadcast output of a webbrowser. A software messenger component resides within the front-end POSsystem in order to accept events from a POS system that are recognizedby the POS system during the retail transaction. The messenger componenttranslates the events into generalized messages that are queued to amessage queuing component. The generalized messages are dequeued fromthe message queuing component by a generating component that generatesweb pages. The generated web pages are made available to a web serverthat provides web pages to the web browser for display on the auxiliarydisplay device included in the front-end POS system. The augmented POSsystem can thus, in real-time, display web pages via the web browsergenerated in response to events that occur during the retailtransaction. The net result is the real-time display to a customer ofspecific information tailored to that customer in the context of theretail transaction.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004]FIG. 1 illustrates a newer-generation POS system.

[0005]FIG. 2 illustrates an example sales receipt and/or monitor displaycorresponding to an example retail transaction.

[0006]FIG. 3 is a high-level flow control diagram for the program “SalesTransaction” that represents a front-end POS application program.

[0007]FIG. 4 is a flow control diagram for the routine “Scan Items.”

[0008]FIG. 5 is a flow control diagram for the routine “ReceivePayment.”

[0009]FIG. 6 displays one embodiment of the promotional retailingsystem.

[0010] FIGS. 7-14 illustrate the retail transaction of FIG. 2 conductedon a promotional retailing system.

[0011]FIG. 15 is a high-level architectural block diagram of thesoftware components, and the interactions between the softwarecomponents, of the promotional retailing system.

[0012] FIGS. 16-18 illustrate different possible hardware configurationson which the various components of the promotional retailing system,shown in FIG. 15, can run.

[0013]FIG. 19 is a flow control diagram describing operation of thepromotional retailing system messenger.

[0014]FIG. 20 is a flow control diagram of the promotional retailingsystem generator software component.

[0015] FIGS. 21A-21B illustrate an example script run by the promotionalretailing system generator.

DETAILED DESCRIPTION OF THE INVENTION

[0016] The present invention provides an augmented POS system, orpromotional retailing system (“PRS”), that provides real-time display,and that may also provide audio broadcast, of promotional information toa customer during a retail transaction. A number of different componentsare embedded within a POS system in order to produce the PRS. Amessenger component is embedded within the front-end POS system in orderto collect the events generated by the POS system, translate thoseevents into generalized messages, and queue the generalized messages toa message queuing system, generally provided by a standard operatingsystem within the front-end POS system or within one or more backroomservers. A generator component runs either on the POS system, a backroomserver, or perhaps an additional computer, to dequeue the generalizedmessages from the queuing system, produce web pages corresponding to thegeneralized messages, and provide those web pages to a web server. Aspecialized web browser component displays and perhaps broadcasts theweb pages on an auxiliary display and broadcast device to a retailcustomer. This system thus provides real-time promotional information tothe retail customer during the course of a retail transaction that canbe specifically tailored to the customer within the context of theretail transaction.

[0017]FIG. 1 illustrates a newer-generation POS system. The front-endportion of the POS system comprises a PC 102 or similar computer systemthat includes a display monitor 104 and one or more input devices, suchas a keyboard 106. The front-end POS system also includes a cash drawercomponent 108 similar to the cash drawer of a cash register machine. Thecash drawer is activated by a front-end POS application program runningon the PC 102. The front-end POS system further includes a printingdevice 110 that prints out a sales receipt at the end of a transaction.The front-end POS system is intended for use at each check out counter111 or similar retail transaction station within a retail salesestablishment.

[0018] The front-end POS system essentially serves the purpose of atraditional cash register machine. A sales clerk scans items to bepurchased using an optical scanner 112 or, alternatively, the keyboard106 or another input device. The front-end application program runningon the PC 102 correlates scanned product identifiers, such as barcodes,with entries within a file or database that describes each product. Suchentries may include a text description of the product, the price of oneunit in which the product is sold, information as to whether the productshould be taxed upon sale, and additional information useful forordering, inventory control, and other operational and management tasksconducted either by the retail establishment or by a computer systemlocated in a remote home office. As the items are scanned, a list ofitems is displayed on the display monitor 104 along with prices andrunning totals, or, in other words, cumulative charges for thetransaction. The front-end POS system is additionally linked by acomputer network to one or more backroom server computers 114. Thebackroom server computer is commonly linked via a telecommunicationslink 116 or a wide area network (“WAN”) to computer systems that residein a remote home office or a remote regional office. The backroom servercomputer 114 contains the management and control software that collectstransaction information from front-end POS systems, processes thecollected information, and both carries out management and maintenancetasks for the retail establishment as well as sending certain of thecollected and processed information via the telecommunications link 116to a remote computer system. The backroom server often, for example,conducts inventory control for the retail establishment, automatedaccounting, and, in addition, conducts statistical analysis or dynamicanalysis of the flow of retail transactions. A remote computer system ina remote office may conduct similar management and maintenance tasks ona company-wide basis, including ordering and arranging for distributionof products to replenish stocks in the retail establishments.

[0019]FIG. 2 illustrates an example sales receipt that may, in addition,be displayed on a monitor, corresponding to an example retailtransaction. The sales receipt may include a header 202 specific to theretail establishment, a date 204 and time 206 of the retail transactionrepresented by the receipt, and a graphic image, promotional message, orother types of advertising 208. Traditionally, the sales receiptincludes an itemized list of the items purchased during the transaction210 with columns that commonly include a text description of each itempurchased 212, the quantity of each item purchased 214, an indication ofwhether the purchase of the item is taxable 216, and a pricecorresponding to the quantity of items purchased multiplied by the priceof the basic unit of sale of the item 218. In addition, the salesreceipt commonly includes various subtotals and a total price for theretail transaction 222. A printed sales receipt may differ in format andcontent from the display produced by the display monitor of thefront-end POS system (104 in FIG. 1).

[0020] FIGS. 3-5 are flow control diagrams for a front-end applicationprogram running on the PC (102 in FIG. 1) of a front-end POS system.FIG. 3 is a high-level flow control diagram for the program “SalesTransaction” that represents a front-end POS application program. Instep 302, the program receives an identification of the customer forwhom the retail transaction will be conducted. The customeridentification may be scanned from a membership card or keyed in by asales clerk according to input from a customer. The program “SalesTransaction” then, in step 304, transmits the customer identificationand an indication of the start of a retail transaction to the backroomserver computer (114 in FIG. 1). In step 306, Sales Transaction receivescertain information from the backroom server related to the customer,including what is commonly referred to as loyalty information. Thisloyalty information may include such information as the number of bonuspoints that the customer has accrued by shopping at the retailestablishment, indications of products that the customer has purchasedrecently in sufficient quantity to qualify for discounts or acceleratedbonus points, and any other information pertaining to the customer. Instep 308, Sales Transaction calls the routine “Scan Items” to processthe scanning of all the items being purchased by the customer. Whenscanning of the items is complete, Sales Transaction, in step 310,displays a final list of items on a display monitor (104 in FIG. 1) andthen, in step 312, calls the routine “Receive Payment” to process thepayment by the customer for the items in the transaction. Following thepayment, Sales Transaction waits, in step 314, for input from the salesclerk indicating that the transaction is complete. When the sales clerkindicates the end of the transaction, then Sales Transaction, in step316, sends a list of the items purchased in the transaction, along withpayment information, to the backroom server and prints out a salesreceipt on the printing device (110 in FIG. 1) of the front-end POSsystem. If input other than an indication of the end of the transactionis received by Sales Transaction following step 314, Sales Transactionreturns to step 308 to continue scanning items and processing thetransaction.

[0021]FIG. 4 is a flow control diagram for the routine “Scan Items.” Instep 402, Scan Items waits for input from the scanning device orkeyboard (112 and 106 in FIG. 1, respectively). When input is provided,Scan Items determines, in step 404, whether the input represents anidentification of a product. If product identification has not beeninput, then, in step 406, Scan Items determines whether an end-of-scanindication has been input by the sales clerk. If so, Scan Items returns,in step 408. Otherwise, Scan Items returns to step 402 to wait forcorrect input. If a product identification was detected in step 404,Scan Items uses the product identification number, in step 406, to lookup a file or database entry that describes the product. Then, using thisinformation, Scan Items, in step 408, determines the quantity and totalprice for the scanned items.

[0022] There are numerous reasons that a sales clerk may have scanned anitem. For instance, the customer may simply have requested that thesales clerk provide the customer with the price. Alternatively, thesales clerk may scan the item in order to delete the item from thetransaction when a customer changes his or her mind after the productwas initially scanned. Finally, the sales clerk may scan the product inorder to add the product to the retail transaction.

[0023] Along with the product identification, the input received in step402 additionally contains an indication of the reason for the scan. Forexample, the sales clerk may depress a button on the scanner (112 inFIG. 1) or input information as to the nature of the scan via thekeyboard (106 in FIG. 1). In step 410, Scan Items determines whether thescan was made to display the price to the customer. If so, then, in step412, Scan Items displays the price and returns to step 402 to wait forfurther input. Otherwise, in step 414, Scan Items determines whether thescan was conducted in order to add the item to the retail transaction.If so, then in step 416, Scan Items adds the description of the itemretrieved into 406 to a list of items that represents the retailtransaction and updates any running totals for the retail transactionand then, in step 418, updates the display representing the retailtransaction that is displayed on the display monitor (104 in FIG. 1) andthen returns to step 402 to wait further input. Otherwise, in step 420,Scan Items determines whether the scan was conducted in order to delete,or void, the item from the retail transaction. If so, then, in step 422,Scan Items deletes the description of the item retrieved in step 406from the list of items that represents the retail transaction, updatesthe display in step 418, and returns to step 402 to await further input.Otherwise, Scan Items returns directly to step 402 to await for correctinput.

[0024]FIG. 5 is a flow control diagram for the routine “ReceivePayment.” In step 502, Receive Payment waits for an indication from thesales clerk, from a card reading machine, or from some other inputmachine, for an indication of the amount of payment, the type ofpayment, and possible additional account information. In step 504,Receive Payment determines whether the customer is paying by creditcard. If so, then Receive Payment, in step 506, connects a transactionwith a bank or credit card service provider to transfer funds and recordthe retail transaction, and then proceeds to step 518, to be discussedbelow. Otherwise, in step 508, Receive Payment determines whether thecustomer is paying by check. If so, then in step 510, Receive Payment,according to information input by a check reading device or via keyboardentry by the sales clerk, verifies the customer's checking account anddetermines the amount of the check, and then proceeds to step 518, to bediscussed below. Otherwise, in step 512, Receive Payment determineswhether a customer has paid in cash. If so, then, in step 514, ReceivePayment determines the amount of cash based on an indication by thesales clerk, and proceeds to step 518, to be discussed below. Otherwise,in step 516, Receive Payment displays an error and returns to step 502.In step 518, Receive Payment displays on the display monitor (104 inFIG. 1) the amount of payment made by the customer and perhaps otherinformation concerning the payment. In step 520, Receive Paymentdetermines whether, based on the payment received, change or cash mustbe returned to the customer. If so, then, in step 522, Receive Paymentdisplays the amount of money to be returned to the customer. Finally, instep 524, Receive Payment returns.

[0025] Of course, there are many additional details that need to behandled by the front-end POS system not illustrated in FIGS. 3-5. Forexample, in FIG. 3, a provision may be made for a customer to change hisor her mind following scanning of the items and abort the retailtransaction. Thus, provision for additional types of input in the ScanItems routine or in the Sales Transaction program might be made todetect such a desire to abort the retail transaction. FIGS. 3-5 areintended to illustrate the general operation of front-end POSapplication programs. There are many alternative ways to implement suchan application program, and many additional features that might beincluded. Various steps in FIGS. 3-5 are labeled with a letter “E”within a circle, such as step 302 in FIG. 3. This labeling indicatesthat the step represents an event that might trigger some furtheractivity within the POS system, as will be discussed below with regardto implementation of the present invention.

[0026]FIG. 6 displays one embodiment of the PRS. This PRS is based onthe newer-generation POS system displayed in FIG. 1. All but onecomponent of the PRS are identical to components of the newer-generationPOS system of FIG. 1 and, in the interest of brevity, will be labeledwith the same labels as used in FIG. 1. The above discussion of thesecomponents will not be repeated.

[0027] The PRS 600 includes an auxiliary display device 602 thatincludes a visual display device and that may include audio speakers forbroadcast of audio information. The PRS components of the describedembodiment are written to generalized interfaces enabling any number ofa variety of different display and broadcast devices to be employed. Theauxiliary display and broadcast device 602 is coupled to the PC 102 andis driven by a specialized web browser, or PRS browser, running on thefront-end POS system PC 102. In alternate embodiments, an additionalcomputer system might be provided to drive the auxiliary display device602, or the display device might be driven from the backroom server 114.The messenger and generator components may run on the PC 102, or one orboth of the generators and messenger components may run on the backroomserver.

[0028] The methods of the present invention can be used to augment anyPOS system to produce the PRS. Although the discussion will focusprimarily on an embodiment of a PRS based on a newer-generation POS,traditional proprietary POS systems can also be augmented to providereal-time display and broadcast of promotional material to a customerwithin the context of a retail transaction. Implementation details ofthe messenger component and generator component may differ depending onthe type of POS being augmented, as will be discussed below, butobject-oriented technologies are employed to isolate and minimize suchdifferences, where possible. Augmentation of any existing POS system toprovide a PRS by the methods of the current invention does not requireany proprietary, single-use hardware devices. Instead, augmentation ofan existing POS system requires standard display devices, and possiblystandard audio broadcast devices, and a number of software components,including the PRS messenger, the PRS generator, a web server, standardmessage queuing facilities and information transfer protocols.

[0029] FIGS. 7-14 illustrate the retail transaction of FIG. 2 conductedon a PRS system. FIGS. 7-14 will be discussed with references to thevarious events indicated in FIGS. 3-5 by labels comprising the letter“E” within a circle. FIGS. 7-14 each show the appearance of theauxiliary display monitor (602 in FIG. 6) at a given instant in time asproduced by the PRS web server.

[0030]FIG. 7 illustrates the output displayed on the auxiliary displaymonitor during the initiation of the retail transaction. After thecustomer has produced a membership card or otherwise indicated thecustomer's identification to the sales clerk, and that customeridentification has been received by the program “Sales Transaction” instep 302 of FIG. 3, Sales Transaction generates an event indicating thereception of the customer identification, and possibly the name of thecustomer, and passes that event to the PRS messenger. The PRS messengerqueues the event which is, in turn, dequeued by the PRS generator inorder to generate a hypertext markup language (“HTML”) or dynamic HTML(“dHTML”) file that describes the output for the auxiliary displaydevice, illustrated in FIG. 7. Thus, if the customer name is availableon the membership card, the PRS is able to generate and display awelcome message specifically tailored to the customer 702 and aninitially blank item list 704. When Sales Transaction receives theloyalty information corresponding to the identified customer, in step306 of FIG. 3, another event may be generated. In response to thisevent, the PRS may display information about bonus points accrued by thecustomer and discounts on particular products, or types of products,available to the customer based on previous purchases. The displayoutput that results from the event generated by the reception of loyaltyinformation as shown in FIG. 8.

[0031] Once the retail transaction has been initiated, the sales clerkbegins scanning individual products brought to the retail sales stationby the customer. The scanning of the products, controlled by the routine“Scan Items” in FIG. 4, may generate a variety of different events,including events corresponding to steps 408, 412, 416 and 422 of FIG. 4.For example, the sales clerk might first scan a one-half galloncontainer of ice cream and then indicate, via a push button or keyboardentry, that there are 3 additional identical items being purchased bythe customer. In response to input by the sales clerk and the scanningof the barcode on the side of the ice cream carton by the scanningdevice (110 in FIG. 1), Scan Items generates an event corresponding tostep 416 of FIG. 4, in which the ice cream is added to the list of itemsrepresenting the retail transaction. In response to that event, the PRSmay generate certain promotional or product information based on theidentity of the item and quantity added to the retail transaction. Forexample, the PRS may be configured to recognize the purchase of arelatively large quantity of a small size of a particular product inorder to display an informational message to the customer indicating theavailability of larger sizes of that product. For example, asillustrated in FIG. 9, the PRS indicates to the customer that ice creamis available in one, two and ten gallon sizes 902, as well as display animage 904 of these larger size containers. Note that any type of displayobject, including bit map representations of static images orrepresentations of video clips, music, or other dynamic media can bedisplayed by the PRS web browser.

[0032] The event generated in step 416 of FIG. 4 corresponding to theaddition of the ice cream to the list of items represented in the retailtransaction also enables the PRS to add an entry for the ice cream tothe display of the transaction 906 and to display running totals oftaxable and nontaxable items, as well as a aggregate running total ofthe price of the transaction 908.

[0033] The customer may have brought an item to the sales counter inorder to simply inquire about the price. When the item is scanned todisplay the price, an event is passed from step 412 of Scan Items to thePRS messenger, ultimately resulting in the display of price information,as shown in FIG. 10. In this case, not only the price of the item 1002is displayed, but also additional promotional information 1004indicating the comparative savings available by purchasing thisparticular item rather than a similar item of a different brand, as wellas an image of the item 1006 and a short video clip 1008 showing asatisfied consumer consuming the item.

[0034] The PRS system may display informational messages, in addition tomerely promotional messages. For example, in response to the addition ofthe next product to the retail transaction, the PRS system may generateconsumer information related to that product that might be of interestto the customer, as shown in FIG. 11.

[0035] In addition to promotional and consumer information, the PRSsystem may also display information concerning discounts or specialprices that become available to the customer upon the scanning andadding to the retail list of a particular item. For example, FIG. 12illustrates the PRS display of discount information 1202 based on thecustomer's purchase of chocolate truffles 1204.

[0036] Once all of the products have been scanned, with intended displayof promotional and informational information by the PRS, the sales clerkrequests and receives payment for the transaction, as controlled by theroutine “Receive Payment” shown in FIG. 5. This routine may alsogenerate numerous different events. For example, the customer may payfor the purchase using a charge card. The charge card transaction, instep 506 in FIG. 5, generates an event leading to the displayillustrated in FIG. 13. In this case, extra bonus points were receivedby the customer because the customer paid for the purchase using an ACMEcharge card. Both the extra bonus points 1302 and an image of an ACMEcharge card 1304 are displayed by the auxiliary monitor.

[0037] Finally, when the transaction is complete, as detected by SalesTransaction in step 316 in FIG. 3, the PRS may present a final displayto the customer that includes promotional information, or otherinformation, based on the entire transaction as well as the customer'sprevious transactions. For example, in FIG. 14, the PRS indicates thetotal number of bonus points accumulated by the customer 1402, thenumber of bonus points required by the customer to receive a prize ordiscount 1404, a list of the prizes for which the customer will qualify1406, and perhaps a promotional message triggered by the types of itemspurchased by the customer during the retail transaction 1408.

[0038] Of course, each different POS system will employ a variety ofdifferent types of front-end POS application programs that may eachgenerate different types of events. These events can be interpreted andtranslated by the PRS system to display any number of different types ofinformation. If the customer is purchasing children's videos, forexample, the PRS system might display a portion of that video on theauxiliary display monitor to entertain the customer's restless children,who might otherwise occupy themselves by grabbing items from candy andmagazine displays adjacent to the sales counter. As web browsertechnology encompasses additional new types of presentationcapabilities, the PRS web browser may, in turn, provide increasedcapabilities for display, including perhaps three dimensional dynamicgraphical displays, surround-sound stereo, or other types of media notyet developed. Even employing those types of media currently availablefor display by web browsers, the PRS provides a rich medium fordisplaying a virtually endless number of different types of promotionaland informational messages.

[0039]FIG. 15 is a high-level architectural block diagram of thesoftware components, and the interactions between the softwarecomponents, that implement a PRS. The PRS includes a standard,currently-available POS system running a POS application program 1502.The POS system exchanges events with a PRS messenger 1504. The PRSmessenger is an object, in the object-oriented programming sense of theword “object,” that provides an exposed interface to the POS system forcollecting events. The PRS messenger 1504 packages the events receivedfrom the POS system 1502 into messages that the PRS messenger 1504queues to a message queue 1506. The message queue used in the PRS may beany number of different message queuing facilities provided by operatingsystem vendors, such as IBM's MQSeries and Microsoft's MSMQ. The PRSgenerator 1508 dequeues messages from the message queue 1506, preparesHTML or dHTML files in response to those messages, and makes the HTML ordHTML files available to a web server 1510. The PRS generator 1508extracts various types of display or broadcast objects from a displayobject database 1512 to include in dHTML files. A dHTML engine 1514prepares the dHTML files with references to the display objects from thedisplay object database 1512 to be included in the image represented bythe file. The PRS generator thus translates each different messagedequeued from the message queue 1506 into one or more web pages, definedby one or more HTML or dHTML files.

[0040] The PRS generator is controlled by high-level script programsthat are prepared to handle the different types of messages generated bythe POS system 1502. A number of different types of scripting languagescan be employed to control the PRS generator, including Microsoft's VBScript and Sun's Java Script. The PRS generator sends indications to theweb server 1510 of the HTML and dHTML files generated in response tomessages so that the web server 1510 can make the web pagescorresponding to the messages available to the PRS browser 1516 thatdisplays the web pages on the auxiliary display device.

[0041] In a preferred embodiment, the messages are encapsulated inextensible markup language (“XML”) data packages. XML data packages areself-describing, so that, for example, a recipient of an XML datapackage can employ standard XML functionality to unpackage the contentsof the XML data package into discrete values having standard data types.It is important to note that the PRS is, in this embodiment, implementedmostly from existing components, including the POS system 1502, themessage queuing facility 1506, the web server 1510, and the dHTML engine1514. The display object database 1512 may be created using a standarddatabase management system (“DBMS”), an object-oriented database system(“OODB”), or a similar type of information storage paradigm. The scriptsthat control the PRS generator can be developed using any number ofdifferent integrated development environments (“IDE”) or commonlyavailable script generators. By this design and methodology, inflexibleproprietary components are avoided. Using standardized, pre-existingcomponents vastly increases the flexibility for modifying and augmentingthe PRS as well as the portability of the methodologies towardsdifferent existing POS systems, and results in lower system costs.

[0042] FIGS. 16-18 illustrate different possible hardware configurationson which the various components of the PRS, shown in FIG. 15, can run.For example, in FIG. 16, the POS system 1502, the PRS messenger 1504,and the PRS browser 1506 all run within the computing engine of theexisting POS system 1602. The remaining components run on a backroomserver 1604 interconnected with the POS computational engine 1602 viacommunications links or a network. By contrast, in FIG. 17, all thecomponents of the PRS, with the exception of the web server 1510, runwithin the computational engine of the front-end POS system 1702 whilethe web server 1510 runs on the backroom server 1704. In yet anotherimplementation, illustrated in FIG. 18, the PRS messenger 1504 runswithin a computational engine of the POS system 1802, the web server1610 runs a backroom server 1804, and the remaining components runwithin a third computer system 1806 added to the front-end POS system inorder to operate the auxiliary display device and provide a suitableenvironment for the PRS generator.

[0043] It should be noted that a retailer may generate a significantamount of revenue by providing promotional displays to vendors of theproducts that the retailer sells. For example, the retailer may agree todisplay promotional information about a manufacturer's product linewhenever a customer purchases one product manufactured by themanufacturer. Thus, not only can a retailer enhance a customer'sshopping experience and inform the customer of opportunities andproducts for sale within the retail store, but also can generate directrevenues by selling advertising space to advertisers. It is importantfor advertisers to be able to verify that the advertisements areactually being displayed to customers. This verification can be providedin the form encrypted data transmitted to the advertiser fromauthenticated sources or, in other words, from known locations. Thus,for example, each time an advertisement is displayed, the PRS maygenerate an encrypted message including authentication information thatis sent via the backroom server computer 114 in FIG. 6 directly to theadvertiser's computer system.

[0044]FIG. 19 is a flow control diagram describing operation of the PRSmessenger. The PRS messenger is a software routine or object-orientedprogramming language object that is incorporated into the existingfront-end POS application program. The front-end POS application programfirst calls a PRS messenger routine, in step 1902, to notify the PRSmessenger of the occurrence of a new event, passing the name of theevent to a PRS messenger. Then, the front-end POS application programpasses to the PRS messenger a number of data elements associated withthe event that has occurred. The PRS messenger receives those dataelements in the for loop comprising steps 1904, 1906, and 1908. First,in step 1904, the PRS messenger receives a next PRS messenger methodindication. In step 1906, the PRS messenger determines whether themethod indication is intended for posting of a data element associatedwith the event to the PRS messenger. If so, then the PRS messenger, instep 1908, receives from the front-end POS application program a name,data type, and value for the data element and stores it in memory.Control then flows back to step 1904 where the PRS messenger is placedto receive a subsequent data element. If no data element was posted instep 1906, then the PRS messenger has received an end of data elementindication from the front-end application program and proceeds toprocess the event and data elements. In step 1910, the PRS messengerconsults a transformation map to possibly transform the name of theevent, or the name, data type, or value of any of the data elementsassociated with the event. Once any transformations have been performed,the PRS messenger packages the event name and data elements togetherinto an XML file in step 1912. In alternative embodiments, a dataencapsulation protocol other than XML can be employed. For example, inplace of the XML encapsulation method and message queuing facility (1506in FIG. 15), a remote procedure call (“RPC”) facility can be employed topackage and transport the event name and data element associated withthe event to the PRS generator (1508 in FIG. 15). Finally, in step 1914,the XML file or, in other words, the message, produced by the PRSmessenger is sent by the PRS messenger to the message queuing facility(1506 in FIG. 15).

[0045]FIG. 20 is a flow control diagram of the PRS generator softwarecomponent. The PRS generator is a process that runs on the computationalengine of the front-end POS system, on a backroom server, or possibly onan additional computer within the PRS system. In step 2002, the PRSgenerator waits for notification of a next message available from themessage queuing facility (1506 in FIG. 15). When another message hasarrived, then, in step 2004, PRS generator acquires the message from themessage queuing facility. In step 2006, the PRS generator parses the XMLfile corresponding to the retrieved message to produce a parse treerepresentation of the contents of the XML file. Note that such a parsetree includes data elements, the name of the event, and any otherinformation that was associated with the event and packaged in themessage by the PRS messenger. In the outer loop comprising steps 2008,2010, 2012, 2014, 2016, and 2018, PRS generator traverses the parse treein some predetermined order. If another parse tree node is discoveredduring the traversal, as determined by PRS generator in step 2010, thenthe inner loop comprising steps 2012, 2013, 2014, 2016, and 2018, isexecuted by PRS generator in order to run scripts triggered by thecontents of the parse tree node. In step 2012, the PRS generator beginsa for loop in which each script is considered. In step 2013, the PRSgenerator determines whether there are more scripts to consider in thefor loop. If not, then control flows back to step 2008 where the nextparse tree node is selected and considered in the outer loop. If anotherscript should be considered, then PRS generator, in step 2014,determines whether the contents of the selected parse tree node triggersthe selected script. If not, then control flows back to step 2012, wherethe next script is selected for consideration. Otherwise, the scripttriggered by the parse tree node is run. Running of the script may causethe PRS generator to access the display object database (1512 in FIG.15), to invoke the dHTML engine (1514 in FIG. 15), to run otherprograms, to communicate with a remote computer via a WAN or network,and do any other types of operations necessary to prepare one or moreHTML or dHTML files that describe the promotional informational displaythat would be displayed to a customer in response to the occurrence ofan event in the POS system that elicited the message currently beingprocessed by the PRS generator. In step 2018, the PRS generatordetermines whether the script has indicated that no further scripts beconsidered. If so, control flows back to step 2008 where the next parsetree node is selected. Otherwise, flow controls back to step 2012 wherethe next script will be selected and considered by the PRS generator.When the nodes of the parse tree have all been traversed, the PRSgenerator in step 2020 sends all the HTML and dHTML files that have beenprepared via running of the script for the currently processed messageto the web server (1510 in FIG. 15). The web server then interacts withthe PRS browser (1516 in FIG. 15) to display a promotional informationalmessage to the customer.

[0046] FIGS. 21A-21B illustrate an example script run by the PRSgenerator. A script may include various tags, such as the tag “BANNER”2102, references to other scripts such as the reference to “TransactionPresentation Banner” 2104, references to display objects, such as“http://www.server.com/freeprnt.swf” 2106, and references to programs,such as the program designated by the string“http://www.server.com/dSIGN” 2108. Each tag, such as tag 2102, isfollowed with a balancing end tag, such as the end tag “/BANNER” 2110.The tags introduce sections of a script that correspond to variousdifferent aspects of a promotional or informational message, criteriafor invoking the script, and various PRS constructs that representcomplex interactions between various PRS components. For example, thetag “SCRIPT” 2112 contains conditional logic that specifies that when aXML message contains a universal price code (“UPC”) equal to the number1234567890, the script should be triggered for execution by the PRSgenerator to carry out the actions specified within the script. One suchaction, for example, is to display a banner within the banner region onthe display monitor that is specified in the script “TransactionPresentation Banner,” as specified in the line introduced by the“BANNER” tag 2102.

[0047] The various PRS components can be implemented in many differenttypes of languages for execution on a variety of different kinds ofhardware platforms. A number of different types of scripting languagescan be devised to specify the construction of promotional andinformational messages to be displayed to a customer. For example,common JAVA script parsers may be employed. A large variety of differentcapabilities can be offered by the script language. For example,inclusion of any number of different types of display and broadcastobjects, including dynamic multimedia objects, such as video clips, oraudio wave files. Different web browsers, web servers, and internalcommunication mechanisms might be used.

[0048] Although the above described embodiment, as illustrated in FIG.15 was described in terms of events being generated on the POS system1502, passed to the PRS messenger 1504, translated by the PRS messenger1504 into XML messages that are passed to the PRS generator 1508 tospecify creation of HTML files describing promotional informationaldisplays to be displayed to a customer via the PRS browser 1516, itshould be noted that the arrows in FIG. 15 are by-directional. If thedisplay monitor on which the promotional and informational messages aredisplayed incorporates a touch-screen capability, then touch-screenevents may be transmitted from the PRS browser 1516 in a reversedirection back to the POS system 1502. This would allow, for example, acustomer to select options from a display menu to affect subsequentevents within a retail transaction.

[0049] The embodiment described above is tailored to use withinretailing systems in order to facilitate retail transactions. Suchsystems may include traditional checkout counter systems, as describedabove, or various other retailing systems, including electronic commercesystems. However, the methodologies of the current invention can beemployed in a variety of other systems and settings. For example, thesemethodologies can be used to augment current kiosk systems to producemore elaborate real-time display of information to a user. In fact,these methodologies could be employed in almost any system in whichinformation is presented to a person run automated system. Examplesinclude computerized systems for displaying control information, such asmodern avionics systems, machinery control systems, monitoring systems,and other complex computer-controlled digital display systems.

[0050] It is intended that the scope of the invention be defined by thefollowing claims and their equivalents:

1. A method for augmenting a computer-controlled display system toprovide multi-media displays to a viewer of the computer controlleddisplay system that are based on the context of an interaction betweenthe viewer and the computer-controlled display, the method comprising:including a messenger component within the computer-controlled displaysystem to receive real-time notification of events detected by thecomputer-controlled display system during the course of the interaction,translating the events into messages, and make the messages availablefor processing by other components; including a generator componentwithin the computer-controlled display system to process messages madeavailable by the messenger component to produce descriptions of themulti-media displays; and including a display component within thecomputer-controlled display system that receives the descriptions of themulti-media displays produced by the generator component and displays tothe multi-media displays to the viewer; and during the course of theinteraction, receiving notifications of events detected by thecomputer-controlled display system; translating the events intomessages; producing descriptions of multi-media displays correspondingto the messages; and displaying the multi-media displays to the vieweraccording to the descriptions of visual displays corresponding tomessages representing the translation of events detected by thecomputer-controlled display system.
 2. The method of claim 1 furtherincluding parsing messages by the generator component and runningscripts by the generator component that specify the production of thedescriptions of the multi-media displays.
 3. The method of claim 1wherein the messenger component makes messages available to thegenerator component by passing the messages to a message queuingfacility and wherein the generator component receives messages from themessage queuing facility.
 4. The method of claim 1 wherein thecomputer-controlled display system passes an event to the messengercomponent by passing the name of the event and data elements associatedwith the event, and wherein the messenger component transforms the eventname and data elements according to a transformation map and packagesthe transformed event name and data elements into a self-describing dataencapsulation object.
 5. The method of claim 1 wherein the displaycomponent includes a web server and a web browser, and wherein thedescriptions of the multi-media displays are hypertext markup languagedocuments or dynamic hypertext markup language documents.
 6. The systemof claim 1 wherein the generator component executes scripts that aretriggered by data values included in the messages, the scriptsspecifying various operations and tasks required to prepare thedescriptions of multi-media displays, including running programs,accessing databases containing display objects to be included in thevisual displays, invoking dynamic hypertext markup language engines forpreparing dynamic hypertext markup language files, and invoking otherscripts.
 7. The system of claim I wherein the generator component tracksthe display of different multi-media displays and reports the number oftimes certain multi-media displays are displayed via a network ortelecommunications link to a remote computer.
 8. The system of claim 1wherein the display component includes a touch screen for receivinginput of responses and indications from the viewer and wherein the inputresponses and indications are passed from the display component back tothe generator component which then passes messages containing theresponses and indications back to the messenger component, the messengercomponent then generating events corresponding to the responses andindications and passing those events to the computer-controlled displaysystem.
 9. A method for augmenting a point of sale system to providemulti-media promotional and informational displays to a customer duringa retail transaction that are based on the context of the retailtransaction, the method comprising: augmenting a front-end point of salesystem to include a multi-media display device for displayingpromotional and informational displays to the customer; including amessenger component within the front-end point of sale system to receivereal-time notification of events detected by the front-end point of salesystem during the course of a retail transaction, translate the eventsinto messages, and make the messages available for processing by othercomponents; including a generator component within the point of salesystem to process messages made available by the messenger component toproduce descriptions of visual displays corresponding to the promotionaland informational displays; including a display component within thepoint of sale system that receives the descriptions of visual displaysproduced by the generator component and displays to the customer thecorresponding promotional and informational displays on the multi-mediadisplay device; and during the course of the retail transaction,receiving notifications of events detected by the front-end point ofsale system; translating the events into messages; producingdescriptions of visual displays corresponding to the messages; anddisplaying promotional and informational multi-media displays to thecustomer on the multi-media display device according to the descriptionsof visual displays corresponding to messages representing thetranslation of events detected by the front-end point of sale system.10. The method of claim 9 further including parsing messages by thegenerator component and running scripts by the generator component thatspecify the production of the descriptions of visual displays.
 11. Themethod of claim 9 wherein the messenger component makes messagesavailable to the generator component by passing the messages to amessage queuing facility and wherein the generator component receivesmessages from the message queuing facility.
 12. The method of claim 9wherein the point of sale system passes an event to the messengercomponent by passing the name of the event and data elements associatedwith the event, and wherein the messenger component transforms the eventname and data elements according to a transformation map and packagesthe transformed event name and data elements into a self-describing dataencapsulation object.
 13. The method of claim 9 wherein the displaycomponent includes a web server and a web browser, and wherein thedescriptions of visual displays are hypertext markup language documentsor dynamic hypertext markup language documents.
 14. The method of claim9 wherein the promotional and informational messages may include varioustypes of multi-media presentation objects, including video clips, stillimages, spoken text, printed text, and music.
 15. An enhanced point ofsale system that provides multi-media promotional and informationaldisplays to a customer during a retail transaction that are based on thecontext of the retail transaction, the system including: a front-endpoint of sale system that includes a multi-media display device fordisplaying promotional and informational displays to the customer; amessenger component within the front-end point of sale system to receivereal-time notification of events detected by the front-end point of salesystem during the course of a retail transaction, translate the eventsinto messages, and make the messages available for processing by othercomponents; a generator component within the point of sale system toprocess messages made available by the messenger component to producedescriptions of visual displays corresponding to the promotional andinformational displays; and a display component within the point of salesystem that receives the descriptions of visual displays produced by thegenerator component and displays to the customer the correspondingpromotional and informational displays on the multi-media displaydevice.
 16. The system of claim 15 wherein the messenger componentpasses messages to the generator component via a message queuingfacility.
 17. The system of claim 16 wherein the generator componentexecutes scripts that are triggered by data values included in themessages, the scripts specifying various operations and tasks requiredto prepare the descriptions of visual displays, including runningprograms, accessing databases containing display objects to be includedin the visual displays, invoking dynamic hypertext markup languageengines for preparing dynamic hypertext markup language files, andinvoking other scripts.
 18. The system of claim 16 wherein the generatorcomponent tracks the display of different visual displays and reportsthe number of times certain visual displays are displayed via a networkor telecommunications link to a remote computer.
 19. The system of claim16 wherein the display component includes a web server and a web browserfor display of hypertext markup language files and dynamic hypertextmarkup language files.
 20. The system of claim 16 wherein the displaycomponent includes a touch screen for receiving customer responses andindications and wherein the customer responses and indications arepassed from the display component back to the generator component whichthen passes messages containing the responses and indications back tothe messenger component, the messenger component then generating eventscorresponding to the responses and indications and passing those eventsto the front-end point of sale system.